Skip to main content

Test CasesDirect link to Test Cases

A test case is a named, ordered set of plain-English steps. It's the unit cloud agent executes — on its own, as part of a test session with other test cases, or on a recurring schedule.

Creating a test caseDirect link to Creating a test case

  1. Go to Test cases.

  2. Click Add Test Case.

  3. Choose a folder (or create a new one) to file it under.

  4. Give it a short title — this is what shows up in the folder tree and in session results (e.g. search, checkout-guest).

  5. Set a Priority from P0 (highest) to P3 (lowest). Priority doesn't change execution — it's for your own triage and reporting.

  6. Add Tags to make the test case filterable later (e.g. smoke, regression, airbnb).

  7. Write Steps, one instruction per line, in plain English:

    1. load the url
    2. enter a destination
    3. add dates
    4. add guests
    5. click on search
    6. validate the search results are inline with the data entered
  8. Save.

Writing good stepsDirect link to Writing good steps

O2 interprets each step against the live page at execution time — it identifies the right element from context (labels, hierarchy, visual role) rather than a fixed selector. To get reliable results:

  • Be specific about intent, not implementation. Write click on search, not click the button with id #search-btn. The former survives a UI redesign; the latter defeats the point of intent-based execution.
  • One action per line. Keep each step to a single, unambiguous action or assertion.
  • End with a validation. A step like validate the search results are inline with the data entered gives O2 something concrete to assert on, and gives you a clear pass/fail signal in the session report.
  • Reference environment data, not environment names. Steps shouldn't hardcode a URL — that's what the environment's base URL is for; a step just needs load the url.

Organizing with foldersDirect link to Organizing with folders

Test cases live in a folder tree (for example /airbnb, /amazon, /devassure, /evershop). Folders are purely organizational:

  • Group test cases by product area, app, or team.
  • Use the folder filter on the Test cases list to scope what you're looking at.
  • Folders can be nested to reflect larger suites.

Editing and historyDirect link to Editing and history

Open any test case to see two tabs:

  • Details — the folder, priority, tags, and steps, all editable inline.
  • History — past executions of this specific test case across sessions, so you can see when it started failing.

Running a test caseDirect link to Running a test case

Click Run from the test case detail view to execute it immediately against a chosen environment on the next available agent — see Test Sessions for what happens next, or Scheduling & CI/CD to automate it.